home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000070_owner-urn-ietf _Wed Nov 6 15:52:05 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  6KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA17065 for urn-ietf-out; Wed, 6 Nov 1996 15:52:05 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA17059 for <urn-ietf@services.bunyip.com>; Wed, 6 Nov 1996 15:51:56 -0500
  3. Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA13528  (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 15:51:38 -0500
  5. Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
  6.           id PAA10773; Wed, 6 Nov 1996 15:32:28 -0500 (EST)
  7. Message-Id: <199611062032.PAA10773@ig.cs.utk.edu>
  8. X-Uri: http://www.cs.utk.edu/~moore/
  9. From: Keith Moore <moore@cs.utk.edu>
  10. To: Martin J Duerst <mduerst@ifi.unizh.ch>
  11. Cc: moore@cs.utk.edu (Keith Moore), tallen@fsc.fujitsu.com,
  12.         urn-ietf@bunyip.com
  13. Subject: Re: [URN] I18N does not belong in URNs 
  14. In-Reply-To: Your message of "Wed, 06 Nov 1996 18:02:19 +0100."
  15.              <"josef.ifi..172:06.10.96.17.02.21"@ifi.unizh.ch> 
  16. Date: Wed, 06 Nov 1996 15:32:28 -0500
  17. Sender: owner-urn-ietf@services.bunyip.com
  18. Precedence: bulk
  19. Reply-To: Keith Moore <moore@cs.utk.edu>
  20. Errors-To: owner-urn-ietf@bunyip.com
  21.  
  22. > >> >> Your
  23. > >> >> last point would have merit were it not that we absolutely must
  24. > >> >> be able to grandfather in existing name spaces.
  25. > >> >
  26. > >> >Yes, we must be able to grandfather existing name spaces *that serve
  27. > >> >similar purposes to URNs*.  ISBNs qualify.  Handles qualify.
  28. > >> >Usenet message-ids qualify.  But URNs don't have to handle existing
  29. > >> >name spaces that don't have the characteristics that URNs have.
  30. > 
  31. > >> And the fact that you
  32. > >> don't know about any such namespaces doesn't guarantee that there
  33. > >> are no such namespaces.
  34. > 
  35. > I thought I didn't know any such namespaces when I wrote this mail.
  36. > But I have become aware that my postal savings account number in
  37. > Japan contains a kanji. The set of kanji in this case is limited
  38. > to one each for each of the central offices that keeps track of
  39. > postal savings accounts. I am very sure also that there are lots
  40. > of other examlpes that fit the requirements of URNs at least as
  41. > well as ISBNs that contain kanji or other non-ASCII characters.
  42.  
  43. Perhaps.  I don't have as big a problem with this, as long as
  44. there's a discipline about how they are assigned that prevents
  45. URNs from being used as search strings.  That's my main worry.
  46. (URNs are also supposed to be transcribable, but I recognize that
  47. only a very small set of characters is transcribable by everyone
  48. on the planet.)
  49.  
  50. Sorry, I can't make heads or tails of this.
  51.  
  52. > So for grandfathering, we have two choices.
  53. > 
  54. > 1) We interpret it as "direct grandfathering of characters",
  55. >     in which case we have to allow a really wide range
  56. >     of characters (i.e. ISO 10646).
  57. > 2) We interpret it as "indirect grandfathering", in which
  58. >     case the digits, or whatever small set, will be
  59. >     enough.
  60.  
  61. I suspect there will be some of each.  But we want the transformations
  62. from "old identifier" to URN to be simple and easy to remember.
  63. Ideally, you just prepend a URN:namespace: string.  In some cases
  64. it may be necessary to remove punctuation; for instance, we might
  65. want to remove '-' characters from ISBNs.  But that gets specified
  66. on a per-namespace basis.
  67.  
  68. > Choosing ASCII only as for URLs would be very unfair cheating.
  69.  
  70. If the names aren't human meaningful, I don't see what you're
  71. complaining about.
  72.  
  73. > >> I definitely hate to see i18n just being moved around and delayed
  74. > >> by some people. With UTF-8 in URNs, we have made great progress.
  75. > >
  76. > >No, this is a big step backward.  Just because there is a new layer
  77. > >being defined doesn't mean that I18N belongs there.  
  78. > >
  79. > >I18N *is* important  -- and I'd be happy to see a draft document or 
  80. > >draft charter for a working group to define a protocol (say an extension
  81. > >of http/html) to resolve human-friendly names into URNs or URLs.
  82. > 
  83. > Why is there a need for an additional protocol layer?
  84. > There is no need currently for English, is it?
  85.  
  86. Yes, there is.  Human-friendly names are inherently ambiguous,
  87. and have ambiguous meanings which require a human being to untangle.
  88. (If I ask for "Julius Caesar", do I mean the Shakespeare play or 
  89. the person or what?  Most people would think the name is unambiguous--
  90. after all, they already know what they have in mind and the other 
  91. meanings will not occur to them.  But if you feed "Julius Caesar"
  92. to a library catalog, you will get back large numbers of hits.
  93. By contrast, if you feed )
  94.  
  95. URNs should be precise enough that a human isn't required to
  96. disambiguate the result.
  97.  
  98. > And I don't want to have to search through long lists
  99. > of possible answers just because I use Japanese, whereas
  100. > I will get one immediate answer for English.
  101.  
  102. The point is that you will often get multiple answers for English.
  103. English names are no more precise than names in other languages.
  104.  
  105.  
  106. > >> Some protocols (notably FTP) are also going in the direction of
  107. > >> UTF-8. Ideally, we will have a uniform solution for both URLs
  108. > >> and URNs, based on UTF-8. 
  109. > >
  110. > >No.  Ideally, if we figure out how to do this, we will have a 
  111. > >uniform solution for all URLs.  I18N (and even E8H :) absolutely 
  112. > >doesn't belong in URNs.
  113. > 
  114. > Well, if URLs are uniformly internationalized, I wouldn't
  115. > mind about URNs. But I know that there are people, and
  116. > this probably includes you, that claim that URLs also
  117. > are not designed to be human-friendly.
  118.  
  119. They weren't *designed* to be human-friendly, and they don't do 
  120. a very good job of it (if nothing else, they're hard to type and you 
  121. can't easily say them out loud).  But URLs tend to reflect their 
  122. underlying file and directory structures, which *are* (sort of)
  123. human-friendly.  (really they're more author-friendly)
  124.  
  125. > >For URNs, human-friendliness will be excluded by design.
  126. > 
  127. > I18N and human-friendliness are not the same thing.
  128. > For direct grandfathering, I18N is needed. If you are
  129. > sure human-friendliness will not sneak into URNs
  130. > with ASCII, it will also not sneak into URNs with
  131. > UTF-8.
  132.  
  133. I think URNs need restrictions on human-friendliness in either case.
  134.  
  135. Keith